GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Anti-Pattern</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Anti-Pattern</span></h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p>Ein <b>Anti-Pattern</b> (aus dem <a href="Englische_Sprache" title="Englische Sprache">Englischen</a>, übersetzt etwa <i>Antimuster</i>) ist ein Oberbegriff für Verhaltensmuster, die speziell in der <a href="Softwareentwicklung" class="mw-redirect" title="Softwareentwicklung">Softwareentwicklung</a> anzutreffen und zumeist auch allgemein auf <a href="Organisation" title="Organisation">Organisationen</a> übertragbar sind. Als Anti-Pattern werden Lösungsansätze bezeichnet, die ungünstig oder schädlich für den Erfolg eines Projektes oder einer Organisation sind. Sie bilden das Gegenstück zu <i>Pattern</i> (englisch <i>Muster</i>), welche gute und bewährte Problemlösungsansätze darstellen.

</p><p>Das Konzept von Mustern wurde vor allem durch die <a href="Entwurfsmuster" title="Entwurfsmuster">Entwurfsmuster</a> aus dem <a href="Entwurfsmuster_(Buch)" title="Entwurfsmuster (Buch)">Buch von 1994: „Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software“</a> (Originaltitel Design Patterns. Elements of Reusable Object-Oriented Software) bekannt. Diese umfassen jeweils eine Beschreibung einer prototypischen Problemsituation samt Lösungsvorschlag. Nachdem Muster in der Softwareentwicklung zunehmend erfolgreich eingesetzt wurden, wurden auch Negativbeispiele thematisiert, um wiederkehrende Fehler zu identifizieren, zu dokumentieren und Maßnahmen zur Behebung aufzuzeigen. So wie sich Muster nicht nur auf den Entwurf von Software beschränken und es auch beispielsweise Kataloge für <a href="Analysemuster" title="Analysemuster">Analysemuster</a>, <a href="Architekturmuster" title="Architekturmuster">Architekturmuster</a> oder <a href="Organisationsmuster" title="Organisationsmuster">Organisationsmuster</a> gibt, beschränken sich auch Anti-Pattern nicht nur auf den <a href="Quelltext" title="Quelltext">Quelltext</a> und die <a href="Softwarearchitektur" title="Softwarearchitektur">Softwarearchitektur</a>, sondern haben häufig Projektmanagement und Unternehmensprozesse zum Gegenstand.

</p><p>In der Regel entstehen Anti-Pattern durch mangelhafte Erfahrung oder fehlende Qualifikation. Zu beobachten ist auch der bewusste Einsatz von Anti-Pattern, um zum eigenen Vorteil einen bestimmten, vom eigentlichen Projektziel abweichenden Zweck zu erreichen.

</p>

<div class="mw-heading mw-heading2"><h2 id="Kategorisierung">Kategorisierung</h2></div>

<p>Mittlerweile werden die Vorkommen von Anti-Pattern immer feiner unterschieden. Sie fächern sich auf von der reinen Software-Programmierung (hier spricht man auch von <a href="Code-Smell" title="Code-Smell">Code-Smells</a>, die bei Existenz und Identifikation durch <a href="Refactoring" title="Refactoring">Refactorings</a> entfernt werden können), gehen weiter zu <a href="Architektur_(Informatik)" title="Architektur (Informatik)">Architektur</a> und <a href="Strukturiertes_Design" title="Strukturiertes Design">Design</a>, wirken im <a href="Projektmanagement" title="Projektmanagement">Projektmanagement</a> und in Unternehmensprozessen und -organisation sowie im Management. Darüber hinaus können in der Praxis häufiger sogenannte Meta-Patterns identifiziert werden. Diese vereinen einzelne Muster zu neuen, abstrakteren Mustern oder führen weitere Dimensionen oder abstraktere Kategorisierungen ein.

</p>

<div class="mw-heading mw-heading3"><h3 id="Projektmanagement-Anti-Pattern">Projektmanagement-Anti-Pattern</h3></div>

<div class="mw-heading mw-heading4"><h4 id="Blendwerk">Blendwerk</h4></div>

<p>Das <i>Blendwerk</i> (englisch <i><span lang="en">Smoke and mirrors</span></i>) bezeichnet nicht fertige Funktionen, welche als fertig vorgetäuscht werden.

</p>

<div class="mw-heading mw-heading4"><h4 id="Aufgeblähte_Software"><span id="Aufgebl.C3.A4hte_Software"></span>Aufgeblähte Software</h4></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Bloatware" title="Bloatware">Bloatware</a></i></div>

<p><i>Aufgeblähte Software</i> bezeichnet Software, die mit unnötigen Zusatzfunktionen oder Ressourcenverschwendung aufgebläht wird und damit den eigentlichen Anwendungszweck kaum oder gar nicht verbessert.

</p>

<div class="mw-heading mw-heading4"><h4 id="Feature_creep">Feature creep</h4></div>

<p><i>Feature creep</i> (<i>Einschleichen von Funktionalität</i>) bezeichnet es, wenn der Umfang der zu entwickelnden Funktionalität in einem <a href="Projektplan" title="Projektplan">Projektplan</a> festgehalten wird, diese aber dauernd erweitert wird.

</p><p>Der Kunde versucht nach der Erstellung des Projektplanes weitere Funktionalität in der Version mit unterzubringen. Dies führt zu Problemen, wenn die in Arbeit befindliche Version nicht das notwendige Design aufweist, Termine nicht eingehalten werden können oder die realen Kosten über die planmäßigen Kosten wachsen.

</p><p>Bei schwergewichtigen <a href="Vorgehensmodell_zur_Softwareentwicklung" title="Vorgehensmodell zur Softwareentwicklung">Prozessen</a> ist dies sehr gefährlich. Bei leichtgewichtigen Prozessen wie <a href="Extreme_Programming" title="Extreme Programming">Extreme Programming</a> (XP) müssen bei allen Beteiligten die Konsequenzen klar sein. Ein systematisches <a href="Anforderungsmanagement" title="Anforderungsmanagement">Anforderungsmanagement</a> und <a href="%C3%84nderungsmanagement" class="mw-redirect" title="Änderungsmanagement">Änderungsmanagement</a> sind obligatorisch. Gewisse Änderungen am Projektplan während der Entwicklung sind in größeren Projekten schwer vermeidbar, denn die Spezifikationen bis ins letzte Detail auszuarbeiten ist meist noch aufwendiger, als etwas Reserve einzuplanen. Auch können Anforderungen erst während der Entwicklung entdeckt werden.

</p><p>Extreme, böswillige und grob fahrlässige Anwendung dieses Musters kann dadurch motiviert sein, dass der Auftraggeber, der immer neue Funktionalität fordert, das Produkt boykottieren möchte und dessen Abschluss zu verhindern sucht, oder er hat bei der Planung bewusst eigentlich benötigte Funktionalität unterschlagen, um eine günstigere Offerte zu erhalten.

</p><p>Durch ein Wortspiel, dessen Inhalt die Wandlung von <i>Creeping Feature</i> zu <i>Feeping Creature</i> umfasst, wird der Umstand ausgedrückt, dass eine Verselbstständigung von Anforderungen und Implementierungen unnötiger oder nicht in das Gesamtkonzept passender Leistungsmerkmale stattgefunden hat.

</p>

<div class="mw-heading mw-heading4"><h4 id="Scope_creep">Scope creep</h4></div>

<p>Der <i>Scope creep</i> (<i>Einschleichen weiterer Anwendungsbereiche</i>) ist ähnlich dem <i><a href="#Feature_creep">Feature creep</a></i>, jedoch nicht auf Funktionalität bezogen, sondern auf den Anwendungsbereich. Auch hier zeichnet sich der Auftraggeber dadurch aus, dass er geschickt und versteckt den Umfang der Software nachträglich erweitern möchte, ohne dass er dies explizit zugibt. Beispiel: nicht diskutierte Anwendungsbereiche sind plötzlich sehr wichtig bzw. das Fehlen eines Bereiches wird sogar als Fehler dargestellt, der dringendst behoben werden muss.

</p>

<div class="mw-heading mw-heading4"><h4 id="Brooks’sches_Gesetz"><span id="Brooks.E2.80.99sches_Gesetz"></span>Brooks’sches Gesetz</h4></div>

<p>Das <i>Brooks’sche Gesetz</i> besagt, dass ein hinter seinem Zeitplan herhinkendes Projekt länger benötigt, wenn neue Mitarbeiter eingestellt werden, weil die neuen Mitarbeiter Zeit benötigen, um sich einzuarbeiten, und sie dabei die etablierten Kollegen abbremsen.

</p>

<p>“Adding manpower to a late software project makes it later.”

</p>

</blockquote>

<p>„Mitarbeiter zu einem verspäteten Softwareprojekt hinzuzufügen, verzögert das Projekt nur noch weiter.“

</p>

</blockquote></div><div class="cite" style="margin:-1em 0 1em 1em;">– <style data-mw-deduplicate="TemplateStyles:r261921330">

/* start https://de.wikipedia.org/ */

.mw-parser-output .Person{font-variant:small-caps}

/* end https://de.wikipedia.org/ */

</style><span class="Person h-card"><a href="Frederick_Brooks" class="mw-redirect" title="Frederick Brooks">Frederick Brooks</a></span><sup id="cite_ref-BROOKS_1-0" class="reference"><a href="#cite_note-BROOKS-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup></div></div>

<div class="mw-heading mw-heading4"><h4 id="Death_Sprint">Death Sprint</h4></div>

<p>Bei einem <i>Death Sprint</i> (<i>Überhitzter Projektplan</i>) wird Software <a href="Iteration" title="Iteration">iterativ</a> bereitgestellt. Die Bereitstellung erfolgt hierbei in einer viel zu kurzen Zeitspanne. Nach außen sieht das Projekt zunächst sehr erfolgreich aus, da immer wieder neue Versionen mit neuen Eigenschaften abgeschlossen werden. Allerdings leidet die Qualität des Produktes sowohl nach außen sichtbar wie auch technisch, was allerdings nur der Entwickler erkennt. Die Qualität nimmt mit jeder „erfolgreichen“ neuen Iteration ab. Der <i>Death Sprint</i> ist das Gegenstück zum <i><a href="#Death_March">Death March</a></i>.

</p>

<div class="mw-heading mw-heading4"><h4 id="Death_March">Death March</h4></div>

<p>Ein <i>Death March</i> (<i>Todesmarsch</i>; gelegentlich auch <i>Himmelfahrtskommando</i>) ist das Gegenstück zu einem <i>Death Sprint</i> (<i>Überhitzten Projektplan</i>; s. o.). Ein Todesmarschprojekt zieht sich ewig hin.

</p><p>In einem optimalen Fall werden zwar Vorabversionen bereitgestellt, welche aber von schlechter Qualität sind. Der Misserfolg ist objektiv sichtbar. Es können keine <a href="Meilensteinplan" class="mw-redirect" title="Meilensteinplan">Meilensteine</a> gehalten werden bzw. es existieren gar keine. Schlimmstenfalls kann eine Konsequenz daraus sein, dass das Projekt kein Projekt mehr ist, sondern nur eine zeitlich nicht abgeschlossene Aneinanderreihung von Aktivitäten. Es fehlen konkrete Zusagen für Termine und Lieferung von Eigenschaften.

</p><p>Ein Todesmarschprojekt kann auch bewusst in Kauf genommen werden, um von Defiziten in der Organisation abzulenken und Entwicklungen zu verschleppen, d. h. so lange an etwas zu entwickeln, bis eine nicht genau spezifizierte Eigenschaft in irgendeiner Form subjektiv funktioniert. Wenn sowohl <a href="Anforderungsmanagement" title="Anforderungsmanagement">Anforderungsmanagement</a> als auch <a href="%C3%84nderungsmanagement" class="mw-redirect" title="Änderungsmanagement">Änderungsmanagement</a> nicht vorhanden sind und das <i>Projekt</i> kein Projekt mehr ist, so schlenkert das Entwicklungsprodukt orientierungslos umher, und seine Qualität nimmt stetig ab.

</p><p>Ein Todesmarschprojekt kann auch mit einem <i>Überhitzten Projektplan</i> (s. o.) kombiniert werden, um nach außen von Planungslosigkeit und Defiziten bei Organisation und Technik abzulenken. Es wird dann Funktionalität als neu dargestellt, die bereits lange existiert, oder es existiert keine Kontrollinstanz, die Notwendigkeit, Relevanz, Form, Korrektheit und Wichtigkeit von bereitgestellter Funktionalität bewertet.

</p>

<dl><dt>Beispiel</dt>

<dd>Neuanforderungen von gestern <i>sind</i> (<i>nicht</i>: beinhalten!) die <a href="Programmfehler" title="Programmfehler">Bugs</a> von morgen.</dd></dl>

<p>Ein Todesmarschprojekt kommt häufig vor, wenn es keine <a href="Stakeholder" title="Stakeholder">Stakeholder</a> gibt, die Interesse an dem Produkt haben, oder wenn der in das Produkt einfließende Aufwand oder sogar das ganze Produkt letztendlich keine Bedeutung/Wichtigkeit hat. In diesem Fall beschäftigt sich die Unternehmung oder die Entwicklungsabteilung nicht selten (mit sich) selbst.

</p>

<div class="mw-heading mw-heading3"><h3 id="Architektur-_bzw._Entwurfs-Anti-Pattern">Architektur- bzw. Entwurfs-Anti-Pattern</h3></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Big_Ball_of_Mud" title="Big Ball of Mud">Big Ball of Mud</a></i></div>

<p><a href="Software" title="Software">Software</a>, die keine erkennbare <a href="Softwarearchitektur" title="Softwarearchitektur">Softwarearchitektur</a> besitzt, wird als <i>Big Ball of Mud</i> (<i>Großer Matschklumpen</i>) bezeichnet.

</p>

<div class="mw-heading mw-heading4"><h4 id="Gasfabrik">Gasfabrik</h4></div>

<p>Als <i>Gasfabrik</i> (englisch <i><span lang="en">Gas factory</span></i>) werden abwertend unnötig komplexe Systementwürfe für relativ simple Probleme bezeichnet.<sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading4"><h4 id="Gottobjekt">Gottobjekt</h4></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Gottobjekt" title="Gottobjekt">Gottobjekt</a></i></div>

<p>Die Begriffe <i>Gottobjekt</i> (englisch <i><span lang="en">god object</span></i>), <i>Gottklasse</i> (<i><span lang="en">God class</span></i>) und <i>Blob</i> bezeichnen ein Objekt, das zu viel weiß bzw. macht. Die Aufteilung nach Verantwortlichkeiten, Kapselung und die Einhaltung von <a href="Entwurfsmuster" title="Entwurfsmuster">Entwurfsmustern</a> helfen, diesem Muster zu begegnen.

</p>

<div class="mw-heading mw-heading4"><h4 id="Innere-Plattform-Effekt">Innere-Plattform-Effekt</h4></div>

<p>Der <i>Innere-Plattform-Effekt</i> (englisch <i><span lang="en">Inner platform effect</span></i>) tritt auf, wenn ein System derartig weitreichende Konfigurationsmöglichkeiten besitzt, dass es letztlich zu einer schwachen Kopie der Plattform wird, mittels derer es gebaut wurde. Ein Beispiel sind Datenmodelle, die auf konkrete (anwendungsbezogene) Datenbanktabellen verzichten und stattdessen mittels allgemeiner Tabellen eine eigene Verwaltungsschicht für die Datenstruktur implementieren mit dem eigentlichen Ziel, die Flexibilität zu erhöhen. Derartige Systeme sind allerdings typischerweise schwer zu beherrschen und leiden häufig unter zusätzlichen Performanceproblemen.

</p>

<div class="mw-heading mw-heading4"><h4 id="Spaghetticode">Spaghetticode</h4></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Spaghetticode" title="Spaghetticode">Spaghetticode</a></i></div>

<p><i>Spaghetticode</i> ist eine sehr kompakte Systemstruktur, die von <a href="Sprungbefehl" class="mw-redirect" title="Sprungbefehl">Sprungbefehlen</a> geprägt ist, deren Kontrollfluss einem Topf Spaghetti ähnelt. Der Code ähnelt einem <a href="Monolith" title="Monolith">monolithischen</a> Block und weist eine besonders schlechte Wartbarkeit und Wiederverwendbarkeit auf.

</p>

<div class="mw-heading mw-heading4"><h4 id="Train_Wreck">Train Wreck</h4></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Train_Wreck_(Anti-Pattern)" title="Train Wreck (Anti-Pattern)">Train Wreck (Anti-Pattern)</a></i></div>

<p>Beim <i>Train Wreck</i> (deutsch in etwa: Zugunglück) werden mehrere Methodenaufrufe hintereinander verkettet, beispielsweise in <code>vertrag.getKunde().getAdresse().getLand()</code>. Dies führt zusätzliche Abhängigkeiten ein und verletzt somit das Prinzip der <a href="Lose_Kopplung" title="Lose Kopplung">losen Kopplung</a>. Dieses Anti-Pattern darf jedoch nicht mit dem sinnvollen <a href="Decorator" title="Decorator">Decorator</a>-Pattern verwechselt werden.

</p>

<div class="mw-heading mw-heading4"><h4 id="Sumo-Hochzeit">Sumo-Hochzeit</h4></div>

<p>Als <i>Sumo-Hochzeit</i> (englisch <i><span lang="en">Sumo Marriage</span></i>) bezeichnet man es, wenn ein <span lang="en"><a href="Fat_Client" title="Fat Client">Fat Client</a></span> unnatürlich stark abhängig von der <a href="Datenbank" title="Datenbank">Datenbank</a> ist.

</p><p>In der Datenbank ist hierbei sehr viel Logik in Form der datenbankeigenen <a href="Programmiersprache" title="Programmiersprache">Programmiersprache</a> positioniert. Beispielsweise in <a href="Oracle" title="Oracle">Oracle</a> mit der Programmiersprache <a href="PL/SQL" title="PL/SQL">PL/SQL</a>. Die ganze <a href="Architektur_(Informatik)" title="Architektur (Informatik)">Architektur</a> ist dadurch sehr unflexibel.

</p><p>Soll die Anwendung zu einer <a href="Internet" title="Internet">Internet</a>-Anwendung migriert oder die Datenbank gewechselt werden, so müssen auf beiden <a href="Schichtenarchitektur" title="Schichtenarchitektur">Schichten</a> (<a href="Fat_Client" title="Fat Client">Client</a> und <a href="Datenbank" title="Datenbank">Datenhaltung</a>) viele Bereiche neu entwickelt werden. Die Systeme sind nicht <a href="Kopplung_(Softwareentwicklung)" title="Kopplung (Softwareentwicklung)">entkoppelt</a>.

</p>

<div class="mw-heading mw-heading4"><h4 id="Integrationsdatenbank">Integrationsdatenbank</h4></div>

<p>Eine Integrationsdatenbank (englisch: <i><span lang="en">integration database</span></i>) ist eine Datenbank, welche von mehreren Anwendungen direkt verwendet wird, um die Synchronisierung zwischen den Anwendungen sicherzustellen.

</p>

<p>“Integration databases – don’t do it! Seriously! Not even with views. Not even with stored procedures.”

</p>

</blockquote>

</div><div class="cite" style="margin:-1em 0 1em 1em;">– <span class="Person h-card">Michael T. Nygard</span>: <cite style="font-style:normal">Release It!</cite><sup id="cite_ref-integrationdatabase_3-0" class="reference"><a href="#cite_note-integrationdatabase-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup></div></div>

<p>Die Alternative zu einer Integrationsdatenbank ist eine <i><span lang="en">Shared Database</span></i>. Hierbei handelt es sich um eine Datenbank, auf welche ein einziger Webservice zugreift. Der Webservice stellt die Funktionalität der Datenbank in Form einer REST- oder SOAP-Schnittstelle bereit und kann von verschiedenen Anwendungen verwendet werden.

</p>

<p>“Take it up a level, and wrap a web service around the database. Then make the web service redundant and accessed through a virtual IP. Build a test harness to verify what happens when the web service is down. That’s an enterprise integration technology. Reaching into another system’s database is just…icky.”

</p>

</blockquote>

</div><div class="cite" style="margin:-1em 0 1em 1em;">– <span class="Person h-card">Michael T. Nygard</span>: <cite style="font-style:normal">Release It!</cite><sup id="cite_ref-integrationdatabase_3-1" class="reference"><a href="#cite_note-integrationdatabase-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup></div></div>

<div class="mw-heading mw-heading3"><h3 id="Programmierungs-Anti-Pattern">Programmierungs-Anti-Pattern</h3></div>

<div class="mw-heading mw-heading4"><h4 id="Doppelt_überprüfte_Sperrung"><span id="Doppelt_.C3.BCberpr.C3.BCfte_Sperrung"></span>Doppelt überprüfte Sperrung</h4></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Doppelt_%C3%BCberpr%C3%BCfte_Sperrung" title="Doppelt überprüfte Sperrung">Doppelt überprüfte Sperrung</a></i></div>

<p>Unerfahrene Entwickler implementieren oft eine als fehlerhaft anzusehende <i>doppelt überprüfte Sperrung</i> (englisch <i><span lang="en">double-checked locking</span></i>). Dies gilt als Antimuster.

</p>

<div class="mw-heading mw-heading4"><h4 id="Zwiebel">Zwiebel</h4></div>

<p>Als <i>Zwiebel</i> (englisch <i><span lang="en">Onion</span></i>) bezeichnet man Programmcode, bei dem neue Funktionalität um (oder über) die alte gelegt wird.

</p><p>Häufig entstehen Zwiebeln, wenn ein Entwickler ein Programm erweitern soll, das er nicht geschrieben hat. Der Entwickler möchte oder kann die bereits existente Lösung nicht komplett verstehen und setzt seine neue Lösung einfach drüber. Dies führt mit einer Vielzahl von Versionen und unterschiedlichen Entwicklern über die Jahre zu einem Zwiebel-System.

</p>

<div class="mw-heading mw-heading4"><h4 id="Copy_and_Paste">Copy and Paste</h4></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Quelltextklon" title="Quelltextklon">Quelltextklon</a></i></div>

<p>Programmierung mittels <a href="Kopieren_und_Einf%C3%BCgen" title="Kopieren und Einfügen">Kopieren und Einfügen</a> (englisch <i><span lang="en">Copy And Paste Programming</span></i>) bezeichnet es, wenn der Programmierer den Code nicht neu entwickelt, sondern sich bereits existenter <a href="Quelltext" title="Quelltext">Quelltexte</a> bedient, aus denen er Passagen herauskopiert.

</p><p>Die Gefahr ist hierbei sehr groß, dass er Fehler mitkopiert oder die Kopie für den neuen Bereich nicht optimal einsatzbereit ist. Der Entwickler reflektiert weniger über sein Programm, als wenn er jede Zeile selbst entwickeln würde. Hierbei handelt es sich um ein fehleranfälliges Vorgehen, wenn der Entwickler nicht weiß, was er eigentlich macht. Die Wartbarkeit des Codes wird reduziert, wenn der (fast) gleiche Programmcode an vielen Stellen vorkommt. Anstatt zu kopieren, sollte eine gemeinsame Funktion ins Auge gefasst werden.

</p>

<div class="mw-heading mw-heading4"><h4 id="Lavafluss">Lavafluss</h4></div>

<p>Ein <i>Lavafluss</i> (englisch <i><span lang="en">Lava flow</span></i> oder <i><span lang="en">Dead Code</span></i>) beschreibt den Umstand, dass in einer Anwendung immer mehr „toter Quelltext“ herumliegt. Dieser wird nicht mehr genutzt. Statt ihn zu löschen, werden im Programm immer mehr Verzweigungen eingebaut, die um den besagten Quelltext herumlaufen oder auf ihm aufbauen. <a href="Redundanter_Code" title="Redundanter Code">Redundanter Code</a> ist der Überbegriff zu totem Code. Er enthält neben dem <a href="Toter_Code" title="Toter Code">toten Code</a> (<span style="font-style:normal;font-weight:normal"><a href="Englische_Sprache" title="Englische Sprache">englisch</a></span> <span lang="en-Latn" style="font-style:italic">dead code</span>) (ausgeführter Code, dessen Ergebnis nie verwendet wird)<sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup> auch unerreichbaren Code (<span style="font-style:normal;font-weight:normal"><a href="Englische_Sprache" title="Englische Sprache">englisch</a></span> <span lang="en-Latn" style="font-style:italic">unreachable code</span>), das ist Code, der aufgrund der <a href="Ablaufsteuerung" title="Ablaufsteuerung">Ablaufsteuerung</a> des gesamten Programms in keinem möglichen Programmablauf erreicht und darum nie ausgeführt werden kann. Oft wird die Bezeichnung toter Code auch synonym mit redundantem Code verwendet.

</p>

<div class="mw-heading mw-heading4"><h4 id="Magische_Werte">Magische Werte</h4></div>

<p>Bei <i>Magischen Werten</i> (englisch <span lang="en">Magic Values</span>) handelt es sich um Daten (<a href="Literal" title="Literal">Literale</a>) mit besonderer Bedeutung. Sie sind <a href="Hartkodiert" title="Hartkodiert">hartkodiert</a> (englisch <i><span lang="en">hardcoded</span></i>) und nur mit besonderem Wissen über die konkrete Verwendung zu verstehen. Solche Werte sollten zentral als <a href="Konstante_(Programmierung)" title="Konstante (Programmierung)">Konstante</a> definiert werden. Bei mehreren zusammengehörigen Werten eignet sich ein <a href="Aufz%C3%A4hlungstyp" title="Aufzählungstyp">Aufzählungstyp</a>.

</p>

<div class="mw-highlight mw-highlight-lang-java mw-content-ltr" dir="ltr"><pre><span></span><span class="kd">public</span><span class="w"> </span><span class="kd">class</span> <span class="nc">Bar</span><span class="w"> </span><span class="p">{</span>

<span class="w"> </span><span class="kd">public</span><span class="w"> </span><span class="kd">static</span><span class="w"> </span><span class="kt">void</span><span class="w"> </span><span class="nf">main</span><span class="p">(</span><span class="n">String</span><span class="o">[]</span><span class="w"> </span><span class="n">args</span><span class="p">)</span><span class="w"> </span><span class="p">{</span>

<span class="hll"><span class="w"> </span><span class="n">bar</span><span class="p">.</span><span class="na">go</span><span class="p">(</span><span class="mi">7</span><span class="p">);</span><span class="w"> </span><span class="c1">// hart codierter Wert</span>

</span><span class="w"> </span><span class="p">}</span>

<span class="w"> </span><span class="kd">public</span><span class="w"> </span><span class="kt">void</span><span class="w"> </span><span class="nf">go</span><span class="p">(</span><span class="kt">int</span><span class="w"> </span><span class="n">param</span><span class="p">)</span><span class="w"> </span><span class="p">{</span>

<span class="w"> </span><span class="k">switch</span><span class="w"> </span><span class="p">(</span><span class="n">param</span><span class="p">)</span><span class="w"> </span><span class="p">{</span>

<span class="w"> </span><span class="k">case</span><span class="w"> </span><span class="mi">1</span><span class="p">:</span><span class="w"> </span><span class="n">System</span><span class="p">.</span><span class="na">out</span><span class="p">.</span><span class="na">println</span><span class="p">(</span><span class="s">"a"</span><span class="p">);</span><span class="w"> </span><span class="k">break</span><span class="p">;</span>

<span class="w"> </span><span class="k">case</span><span class="w"> </span><span class="mi">3</span><span class="p">:</span><span class="w"> </span><span class="n">System</span><span class="p">.</span><span class="na">out</span><span class="p">.</span><span class="na">println</span><span class="p">(</span><span class="s">"b"</span><span class="p">);</span><span class="w"> </span><span class="k">break</span><span class="p">;</span>

<span class="w"> </span><span class="k">case</span><span class="w"> </span><span class="mi">7</span><span class="p">:</span><span class="w"> </span><span class="n">System</span><span class="p">.</span><span class="na">out</span><span class="p">.</span><span class="na">println</span><span class="p">(</span><span class="s">"c"</span><span class="p">);</span><span class="w"> </span><span class="k">break</span><span class="p">;</span>

<span class="w"> </span><span class="k">case</span><span class="w"> </span><span class="mi">12</span><span class="p">:</span><span class="w"> </span><span class="n">System</span><span class="p">.</span><span class="na">out</span><span class="p">.</span><span class="na">println</span><span class="p">(</span><span class="s">"d"</span><span class="p">);</span><span class="w"> </span><span class="k">break</span><span class="p">;</span>

<span class="w"> </span><span class="k">default</span><span class="p">:</span><span class="w"> </span><span class="n">System</span><span class="p">.</span><span class="na">out</span><span class="p">.</span><span class="na">println</span><span class="p">(</span><span class="s">"x"</span><span class="p">);</span><span class="w"> </span><span class="k">break</span><span class="p">;</span>

</pre></div>

<div class="sieheauch" role="navigation" style="font-style:italic;"><span class="sieheauch-text">Siehe auch</span>: <a href="Magische_Zahl_(Informatik)" title="Magische Zahl (Informatik)">Magische Zahl (Informatik)</a></div>

<div class="mw-heading mw-heading4"><h4 id="Reservierte_Wörter"><span id="Reservierte_W.C3.B6rter"></span>Reservierte Wörter</h4></div>

<p>Die Verwendung von reservierten Wörtern, etwa in <a href="SQL" title="SQL">SQL</a>-Anweisungen, kann zu schwer zu findenden Fehlern führen. Ein Austausch der <a href="Datenbank" title="Datenbank">Datenbank</a> eines Herstellers gegen ein anderes Produkt kann dazu führen, dass weitere Namen als reserviert betrachtet werden müssen. Dem lässt sich entgegenwirken, indem Bezeichner und Zeichenketten durchgängig mit entsprechenden Start- und Endmarkern (z. B. Anführungszeichen) versehen werden.

</p>

<div class="mw-heading mw-heading4"><h4 id="Unbeabsichtigte_Komplexität"><span id="Unbeabsichtigte_Komplexit.C3.A4t"></span>Unbeabsichtigte Komplexität</h4></div>

<p>Als <i>Unbeabsichtigte Komplexität</i> (englisch <i><span lang="en">Accidental complexity</span></i>) wird eine programmierte Lösung bezeichnet, welche komplexer ist, als es für das zu lösende Problem erforderlich und angemessen wäre. Dieses Anti-Pattern ist verwandt mit der <a href="#Gasfabrik">Gasfabrik</a>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Organisations-,_Management-_bzw._Prozess-Anti-Pattern"><span id="Organisations-.2C_Management-_bzw._Prozess-Anti-Pattern"></span>Organisations-, Management- bzw. Prozess-Anti-Pattern</h3></div>

<div class="mw-heading mw-heading4"><h4 id="Wunderwaffe">Wunderwaffe</h4></div>

<p>Eine<i> Wunderwaffe</i> (englisch <i><span lang="en">Golden hammer</span></i>) ist ein bevorzugter Lösungsweg, der als universell anwendbar angesehen wird.

</p>

<p>“if all you have is a hammer, everything looks like a nail.”

</p>

</blockquote>

<p>„Wenn man nur einen Hammer hat, sieht alles wie ein Nagel aus.“

</p>

</blockquote></div><div class="cite" style="margin:-1em 0 1em 1em;">– <span class="Person h-card"><a href="Abraham_Maslow" title="Abraham Maslow">Abraham Maslow</a></span><sup id="cite_ref-5" class="reference"><a href="#cite_note-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup></div></div>

<div class="mw-heading mw-heading4"><h4 id="Das_Rad_neu_erfinden">Das Rad neu erfinden</h4></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Not-invented-here-Syndrom" title="Not-invented-here-Syndrom">Not-invented-here-Syndrom</a></i></div>

<p>Mit <i>das Rad neu erfinden</i> (englisch <i><span lang="en">Reinventing the wheel</span></i> bzw. <i><span lang="en">Not-invented-here-Syndrom</span></i>) wird die stetige Neuerstellung von Software – ohne bestehende Lösungen oder <a href="Framework" title="Framework">Frameworks</a> zu nutzen – bezeichnet. Da keine Wiederverwendung erfolgt, erhöht sich der Entwicklungsaufwand, was zu unreiferer und teurerer Software (im Vergleich zu der Nutzung der bestehenden Software) führt.

</p>

<div class="mw-heading mw-heading4"><h4 id="Das_quadratische_Rad_neu_erfinden">Das quadratische Rad neu erfinden</h4></div>

<p>Mit <i>das quadratische Rad neu erfinden</i> (englisch <i><span lang="en">Reinventing the square wheel</span></i>) bezeichnet man die Bereitstellung einer schlechten Lösung, wenn eine gute Lösung bereits existiert.

</p>

<div class="mw-heading mw-heading4"><h4 id="Body_ballooning"><span lang="en">Body ballooning</span></h4></div>

<p>Beim <i><span lang="en">Body ballooning</span></i> handelt der Vorgesetzte ausschließlich aus der Bestrebung heraus, seine Machtposition auszubauen, welche sich entweder aus der Unternehmensstruktur oder auch rein subjektiv aus der Anzahl der Mitarbeiter unter sich definiert. Dies kann dazu führen, dass der Vorgesetzte bewusst arbeitsintensivere Lösungen und Arbeitstechniken den effizienten vorzieht.

</p>

<div class="mw-heading mw-heading4"><h4 id="Empire_building"><span lang="en">Empire building</span></h4></div>

<p>Durch sachlich nicht nachvollziehbare und nicht konstruktive Maßnahmen versucht eine einzelne Person, ihre Macht auszubauen bzw. zu erhalten. Dies kann <i><span lang="en">Body ballooning</span></i> sein, aber auch das ständige Beschuldigen anderer, gerade derer, die nicht mehr für die Unternehmung arbeiten, die Ausführung von pathologischer Politik, <a href="Diskreditierung" title="Diskreditierung">Diskreditierung</a>, <a href="Mobbing" title="Mobbing">Mobbing</a> und sonstige Facetten, die nur darauf abzielen, die eigene Position zu stärken bzw. den eigenen Status zu halten. Dieses Muster zeichnet sich auch dadurch aus, dass die Person es vermeidet, Verantwortung zu übernehmen, und schriftliche Beweise für Vorkommnisse und Entscheidungen zu verhindern weiß. Somit muss sie sich an diesen nicht messen lassen, was es auch erleichtert, die Verantwortung für das Misslingen eines Projektes an eine andere Person einfach weiter zu delegieren. Hier wird auch bevorzugt jemand ausgewählt, der faktisch nur die Entscheidungen umgesetzt hat (wie ein <a href="Programmierer" class="mw-redirect" title="Programmierer">Programmierer</a> die Entscheidungen des Vorgesetzten oder ein <a href="Projektleiter" title="Projektleiter">Projektleiter</a> die Anforderungen des Kunden umsetzt).

</p>

<div class="mw-heading mw-heading4"><h4 id="Warme_Leiche"><span id="Warmer_K.C3.B6rper"></span><span id="Warmer_Körper"></span> Warme Leiche</h4></div>

<p>Eine <i>warme Leiche</i> (englisch <i><span lang="en">warm body</span></i>) bezeichnet eine Person, die einen zweifelhaften oder keinen Beitrag zu einem Projekt leistet.

</p>

<div class="mw-heading mw-heading4"><h4 id="Single_head_of_knowledge"><span lang="en">Single head of knowledge</span></h4></div>

<p>Ein <i><span lang="en">Single head of knowledge</span></i> ist ein Individuum, welches zu einer Software, einem Werkzeug oder einem anderen eingesetzten Medium als einziges unternehmensweit das Wissen besitzt. Dies zeugt häufig von fehlendem <a href="Wissensmanagement" title="Wissensmanagement">Wissensmanagement</a>, mangelndem Austausch zwischen den Kollegen oder Defiziten in der Organisation, kann aber auch von dem Individuum bewusst angestrebt worden sein.

</p><p>Wenn das Individuum die Unternehmung verlässt, nimmt es bildlich gesprochen das Wissen mit, was für die Unternehmung sehr gefährlich ist. Die Unternehmung blutet <a href="Metapher" title="Metapher">metaphorisch</a> aus (<i><span lang="en">bleeding</span></i>).

</p><p>Das Muster kann durch geeignete Maßnahmen verhindert werden. Beispielsweise durch Entwicklung nach <a href="Extreme_Programming" title="Extreme Programming">XP</a> und <a href="Teambuilding" class="mw-redirect" title="Teambuilding">Teambuilding</a>-Veranstaltungen zusammen mit Mitarbeiterbindung, Motivation und Förderung der Identifikation mit der Unternehmung, um die Fluktuation zu minimieren. Auch eine ordnungsgemäße Dokumentation, auf die alle betroffenen Mitarbeiter Zugriff haben, verhindert einen <i><span lang="en">Single head of knowledge</span></i>.

</p>

<div class="mw-heading mw-heading4"><h4 id="Mushroom_management"><span lang="en">Mushroom management</span></h4></div>

<p>Beim <i><span lang="en">Mushroom management</span></i> werden Mitarbeiter uninformiert und klein gehalten. Hierbei gilt sinngemäß der Grundsatz:

</p>

<p>“Keep them in the dark and feed them full of shit.”

</p>

</blockquote>

<p>„Lass sie im Dunkeln und fütter sie mit Scheiße.“

</p>

</blockquote></div><div class="cite" style="margin:-1em 0 1em 1em;">– <cite style="font-style:normal"><a href="Urban_Dictionary" title="Urban Dictionary">Urban Dictionary</a></cite><sup id="cite_ref-6" class="reference"><a href="#cite_note-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup></div></div>

<p>Entfaltung und Selbstverwirklichung finden beim <i><span lang="en">Mushroom management</span></i> kaum statt. Die Analogie der Belegschaft zu einem Pilzfeld zeichnet sich dadurch aus, dass die Mitarbeiter bildlich mit Mist bedeckt und im Dunkeln gehalten werden und, wenn sie zu groß geworden sind (zu viel Erfahrung, zu gute Leistungen etc.), klein gemacht, unter Druck gesetzt oder gar entlassen werden. Diese <a href="Assoziation_(Psychologie)" title="Assoziation (Psychologie)">Assoziation</a> beinhaltet ferner, dass die Führung Entscheidungen fällt, ohne die Spezialisten zu konsultieren bzw. die Belegschaft über diese Entscheidungen nicht informiert. Häufig ist auch zu beobachten, dass das Management die individuellen Fähigkeiten, Stärken, Schwächen und <a href="Teamrolle" title="Teamrolle">Rollen</a> der Teammitglieder nicht kennt und manchmal sogar auch nicht kennen will (Personen werden gleichgeschaltet: Zugeben, dass jemand mehr kann als die anderen, macht ihn mächtiger, was vermieden werden soll).

</p>

<div class="mw-heading mw-heading4"><h4 id="Noch_ein_Meeting_mehr_wird_es_lösen"><span id="Noch_ein_Meeting_mehr_wird_es_l.C3.B6sen"></span>Noch ein Meeting mehr wird es lösen</h4></div>

<p><i>Noch ein Meeting mehr wird es lösen</i> (englisch <i><span lang="en">Yet Another Meeting Will Solve It</span></i>) bezeichnet es, wenn ein Meeting in einem verspäteten Projekt (d. h. ein Projekt mit Verzug) einberufen wird, wodurch sich der Verzug nur noch mehr erhöht.<sup id="cite_ref-7" class="reference"><a href="#cite_note-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading4"><h4 id="Net_Negative_Producing_Programmer"><span lang="en">Net Negative Producing Programmer</span></h4></div>

<p>Ein <i><span lang="en">Net Negative Producing Programmer</span></i> ist ein unperformanter, unproduktiver Entwickler. Diesen aus einem Team zu entfernen kann die Projektproduktivität mehr erhöhen, als einen guten Entwickler hinzuzufügen und den unproduktiven zu belassen.

</p>

<div class="mw-heading mw-heading4"><h4 id="Management_nach_Zahlen">Management nach Zahlen</h4></div>

<p><i>Management nach Zahlen</i><sup id="cite_ref-8" class="reference"><a href="#cite_note-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup> (englisch <i><span lang="en">Management by numbers</span></i>) ist eine Anspielung auf <a href="Malen_nach_Zahlen" title="Malen nach Zahlen">Malen nach Zahlen</a>. Beim Management nach Zahlen

wird ein übermäßiger Schwerpunkt auf das quantitative Management gelegt. Insbesondere wenn Fokus auf Kosten gelegt wird, während andere Faktoren wie Qualität vernachlässigt werden.

</p><p>Bei diesem Muster werden Programmierer gerne als „Gebrauchsgut“ (englisch <i><span lang="en">commodity</span></i>) gesehen und als austauschbar betrachtet. Dies ist eine sehr kurzfristige Denkweise, die nicht berücksichtigt, dass fehlende Mitarbeiter<a href="Motivation" title="Motivation">motivation</a> oder Mitarbeiter<a href="Fluktuation" title="Fluktuation">fluktuation</a> mittel- bis langfristig deutlich höhere Kosten für das Unternehmen nach sich ziehen können als eine kurzfristige <a href="Investition" title="Investition">Investition</a> in diese.

</p><p>Hier ist auch der Begriff der Softwarefabrik (<i><span lang="en">Software Factory</span></i>) anzuführen, der Versuch, die Softwareentwicklung zu automatisieren und den Programmierer als austauschbaren <a href="Produktionsfaktor" title="Produktionsfaktor">Produktionsfaktor</a> zu betrachten. Dies berücksichtigt allerdings nur unzureichend, dass die Softwareentwicklung zu einem großen Teil ein kreativer, künstlerischer Prozess ist, der Freiraum und optimalerweise auch hohe Entfaltungsmöglichkeit sowie (optimalerweise <a href="Intrinsisch" title="Intrinsisch">intrinsische</a>) <a href="Motivation" title="Motivation">Motivation</a> des Entwicklers voraussetzt. Ferner gilt es zu bedenken, dass Mitarbeiter über die Zeit viel Erfahrung bei der Arbeit an einem Produkt aufbauen, die dem Unternehmen zu einem großen Teil verloren geht, wenn denn die Person die Unternehmung verlässt.

</p>

<div class="mw-heading mw-heading4"><h4 id="Angst_vor_Erfolg">Angst vor Erfolg</h4></div>

<p><i>Angst vor Erfolg</i> (englisch <i><span lang="en">Fear Of Success</span></i>), auch <i>Atmosphäre der Angst</i> bezeichnet es, wenn das Management für eine angstbesetzte, defensive Atmosphäre sorgt. Dies gleicht einem Fußballteam, das nur das eigene Tor verteidigt, ohne Bestrebungen zu haben, selbst ein Tor zu schießen.

</p><p>In einer Kultur voller Angst kann kaum etwas Konstruktives entstehen. Auch etwas Gutes erstellende Personen brechen ihr Vorhaben ab, weil sie davon ausgehen, dass sie sowieso verlieren oder die gute Lösung nicht honoriert bzw. als schlecht dargestellt wird.

</p><p>Unternehmen unter Angst wirken gelähmt und versäumen es, neue Märkte und Lösungen aktiv anzugehen. Sowohl ganze Unternehmungen als auch Abteilungen oder einzelne Personen verlieren so ihre <a href="Wettbewerbsf%C3%A4higkeit" title="Wettbewerbsfähigkeit">Wettbewerbsfähigkeit</a>. Angst, durch Erfolge aufzufallen und so den Argwohn der Kollegen oder des Managements auf sich zu ziehen, verhindert ebenfalls, dass Mitarbeiter und Unternehmungen ihre volle Leistungsfähigkeit abrufen. Nicht selten sehen schlechte Manager in sehr guten Angestellten eine Gefahr, da diese eine Konkurrenz auf ihre Position sind.

</p><p>Typische Aussage: „Ich mache das heimlich. Es ist zwar die beste Lösung, ich will aber nicht, dass der Chef davon erfährt.“

</p>

<div class="mw-heading mw-heading4"><h4 id="Falscher_System-Architekt">Falscher System-Architekt</h4></div>

<p>Ein <i>falscher <a href="Systemarchitekt" class="mw-redirect" title="Systemarchitekt">Systemarchitekt</a></i> (englisch <i><span lang="en">Faux System Architects</span></i>) wird ggf. hinzugezogen, wenn das Management erkennt, dass es bei den Fähigkeiten der Programmierer große Unterschiede gibt. Das Management sucht sich hierbei eine Person aus, die vermeintlich überwältigende Fähigkeiten hat, etwa sowohl bei der Software-Entwicklung als auch beim Umgang mit Leuten – gerade mit Personen, deren Qualifikation unterdurchschnittlich ist.

</p><p>Die Person wird mit einer hohen Erwartungshaltung des Managements eingesetzt und ist häufig ein <a href="Softwarearchitektur" title="Softwarearchitektur">Architekt</a>, oft aber auch ein anderer fachlicher Vorgesetzter. Bei der Auswahl werden interne Spezialisten nicht gefragt, sondern das Management entscheidet selbst und alleine, obwohl es nur schwer selbst entscheiden kann, ob jemand ein guter Software-Entwickler ist.

</p><p>Lange Zeit läuft dies auch recht gut, da sich der vermeintliche Experte recht gut verkaufen kann und sich auch verbal sehr geschickt auszudrücken weiß. Über die Zeit wird aber immer deutlicher, dass die Erwartungen an den Architekten zu hoch waren. Einerseits an der nicht eingetretenen Verbesserung der Software oder der gleichbleibend schlechten Qualität der schlechten Programmierer, andererseits an einer Unzufriedenheit der guten Programmierer. Er kann die blumigen, fast blinden Erwartungen in ihn nicht erfüllen. Bei der Beurteilung des Systemarchitekten gilt es insbesondere immer das Projekt als ein Ganzes zu betrachten. So kann die gleichbleibend schlechte Qualität schlechter Programmierer sehr wohl auch in Umständen begründet sein, auf die auch ein guter Systemarchitekt absehbar keinen Einfluss nehmen kann. Gute System-Architekten können ihrer Position entsprechend auch Opfer von <i><a href="#Body_ballooning"><span lang="en">Body ballooning</span></a></i> oder <i><a href="#Empire_building"><span lang="en">Empire building</span></a></i> (s. o.) werden. Ein guter Systemarchitekt wird z. B. nicht über Wochen oder Monate hin versuchen, die Qualität schlechter Programmierer zu verbessern, wenn sich für ihn absehbar kein Potential erkennen lässt. Von einem schlechten Management vorgegebene unrealistische Rahmenbedingungen degradieren u. a. auch den besten Systemarchitekten. Sollten solche Umstände bekannt sein, der Systemarchitekt aber trotzdem keine Anzeichen machen, das Unternehmen zu verlassen, könnte es sich tatsächlich um einen schlechten Systemarchitekten handeln.

</p>

<div class="mw-heading mw-heading4"><h4 id="Crocodile_Management">Crocodile Management</h4></div>

<p>Beim <i>Crocodile Management</i> ist der Projektleiter nur teilweise im Projekt anwesend und kümmert sich nur um Details, die der Projektmitarbeiter nicht erledigt hat. In Bezug auf das Verhalten eines Krokodils kennzeichnet sich das des Projektleiters hierbei durch:

</p>

<ol><li><i>auftauchen</i></li>

<li><i>Maul aufreißen</i></li>

<li><i>abtauchen</i></li></ol>

<div class="mw-heading mw-heading4"><h4 id="Programmer_Interrupt"><span lang="en">Programmer Interrupt</span></h4></div>

<p>Ein <i><span lang="en">Programmer Interrupt</span></i><sup id="cite_ref-9" class="reference"><a href="#cite_note-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup> liegt dann vor, wenn der Programmierer während seiner Arbeit unterbrochen wird. Hierzu gehören Äußerungen von Kollegen, E-Mails, anstehende Meetings und ähnliches. Studien zufolge benötigt ein Programmierer nach einer Unterbrechung zwischen 10 und 15 Minuten, um wieder effektiv weiterarbeiten zu können, bekommt aber nur etwa einmal am Tag die Möglichkeit, für mehr als zwei Stunden ohne Unterbrechung arbeiten zu können.<sup id="cite_ref-pi-strategie_10-0" class="reference"><a href="#cite_note-pi-strategie-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup> Die Unterbrechung ist umso schwerwiegender, je höher die geistige Beanspruchung des Programmierers während seiner Tätigkeit ist.<sup id="cite_ref-11" class="reference"><a href="#cite_note-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup>

</p><p>Besonders problematisch sind hierbei Unterbrechungen<sup id="cite_ref-12" class="reference"><a href="#cite_note-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup>

</p>

<ul><li>während der Bearbeitung von mehreren Codeabschnitten gleichzeitig,</li>

<li>während Suchaktivitäten zu Programmierproblemen,</li>

<li>während des Durchdenkens des Programmablaufs; insbesondere bei parallelem Code,</li>

<li>durch die der Entwickler die <a href="Integrierte_Entwicklungsumgebung" title="Integrierte Entwicklungsumgebung">Integrierte Entwicklungsumgebung</a> aus dem Sichtbereich verliert.</li></ul>

<p>Typischerweise versuchen Entwickler möglichen Unterbrechungen mit <a href="Kopfh%C3%B6rer" title="Kopfhörer">Kopfhörern</a>, dem Schließen des <a href="E-Mail-Programm" title="E-Mail-Programm">E-Mail-Programms</a> und teilweise dem Abschalten des <a href="Mobiltelefon" title="Mobiltelefon">Mobiltelefons</a> zu begegnen. Weitergehend wenden Entwickler Methoden an, um sich möglichst schnell wieder einarbeiten zu können, hierzu gehören <a href="To-do-Liste" title="To-do-Liste">To-do-Listen</a>, bewusst hervorgerufene <a href="Compiler" title="Compiler">Kompilierungsfehler</a> (etwa durch <a href="Modultest" title="Modultest">Modultests</a>) und <a href="Klebezettel" title="Klebezettel">Klebezettel</a>.

</p><p>Unterbrechungen des Arbeitsablaufs lassen sich jedoch nicht nur bei Entwicklern, sondern bei allen Büroangestellten beobachten.<sup id="cite_ref-13" class="reference"><a href="#cite_note-13"><span class="cite-bracket">[</span>13<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading4"><h4 id="Micromanagement">Micromanagement</h4></div>

<p>Beim <a href="Mikromanagement_(BWL)" title="Mikromanagement (BWL)">Mikromanagement</a> bestimmt ein (möglichst hoher) Manager die Prioritäten und Aufgaben der Programmierer in sehr kleinen Zeiteinheiten neu, ohne die Komplexität der Aufgaben zu verstehen. Das führt sowohl zu <i>Programmer Interrupt</i> als auch zu <i>Mehr Meetings</i> (siehe dort) und es geht die notwendige Flexibilität der Zeiteinteilung verloren, denn auch der beste Entwickler kann nicht auf die Stunde genau sagen, wie lange eine Aufgabe dauern wird.

</p>

<div class="mw-heading mw-heading4"><h4 id="Weitere">Weitere</h4></div>

<ul><li><a href="Softwareerosion" title="Softwareerosion">Software verrotten lassen</a></li></ul>

<div class="mw-heading mw-heading3"><h3 id="Meta-Muster">Meta-Muster</h3></div>

<div class="mw-heading mw-heading4"><h4 id="Programmer_Experience_Clumping"><span lang="en">Programmer Experience Clumping</span></h4></div>

<p>Unerfahrene Programmierer sind meistens bereit, für eine relativ geringe Vergütung für ein Unternehmen zu arbeiten (z. B. aus Unwissenheit oder um dort Erfahrung zu sammeln). Häufig werden in solchen Unternehmen die Programmierer vom Management nicht geschätzt (meistens in Firmen, in denen <i><span lang="en">Management by numbers</span></i> vorherrscht). Es liegen schlechte Arbeitsbedingungen vor. Die unerfahrenen Programmierer können sich nicht weiterentwickeln.

</p><p>Erfahrene Spezialisten sehen, was passiert, und können dies objektiv und kritisch einschätzen. Diese werden den Arbeitsplatz wechseln, um eine Herausforderung anzunehmen, in der die Programmierung besser verstanden und gute Arbeit gewürdigt wird. Dies produziert einen Gruppierungseffekt, in dem sich unerfahrene Programmierer im Unternehmen gruppieren bzw. dort verbleiben und die erfahrenen Leute sich woanders gruppieren. Es kommt zu einer hohen Fluktuation, bei der immer mehr gute Leute das Unternehmen verlassen.

</p><p>Ohne die Führung der erfahrenen Kollegen können die unerfahrenen oder neu eingestellten Entwickler sich nicht verbessern. Ein Teufelskreis entsteht, der auch dadurch verstärkt wird, dass der Arbeitgeber seine (vermeintlich weniger loyalen) Angestellten zu immer weniger Schulungen schickt, da er Angst hat, die Personen verlassen das Unternehmen sowieso und das Geld wäre fehlinvestiert. Irgendwann weiß niemand im Unternehmen mehr, wie ein erfahrener, guter Entwickler aussieht bzw. es fehlt der <a href="Benchmark" title="Benchmark">Benchmark</a>: die unerfahrenen Entwickler merken immer weniger, dass sie eigentlich unerfahren sind.

</p><p><i><span lang="en">Programmer Experience Clumping</span></i> ist nicht auf Programmierer beschränkt, auch IT-fremde Fachabteilungen können betroffen sein. Ein <a href="Abspaltung_(Softwareentwicklung)" title="Abspaltung (Softwareentwicklung)">Derivat</a> des Anti-Patterns ist, dass die guten Leute aus Bequemlichkeit oder anderen persönlichen Gründen zwar im Unternehmen verbleiben, ihre enorme Leistungsfähigkeit allerdings so drosseln, dass sie nur noch ein kleines Stück besser sind als die schlechten Mitarbeiter. Da dies ausreicht, um sich abzugrenzen und die Position zu sichern, schöpfen die guten Mitarbeiter bei weitem ihr Potential nicht aus. Dies ist letztendlich für alle Beteiligten, vor allem aber für das Unternehmen, sehr bedenklich.

</p>

<div class="mw-heading mw-heading4"><h4 id="Zersetzung">Zersetzung</h4></div>

<p>Eine <i>Zersetzung</i> (englisch <i><span lang="en">Corrosion</span></i>) bezeichnet die gewollte oder ungewollte Nutzung einer Vielzahl von Anti-Pattern aus allen Bereichen. Dies geht einher mit konsequenter Verteidigung des Vorgehens, ist meist unsachlich, brachial und ohne Diskussion. Man kommt unweigerlich zu dem Schluss, der Anwendende möchte der Unternehmung oder dem Softwareprodukt grob fahrlässig Schaden zufügen bzw. dessen erfolgreiche und/oder kostengünstige Einführung verhindern. Dies kann auch dadurch motiviert sein, dass der Anwendende einer anderen involvierten Partei schaden will.

</p>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li>Frederick P. Brooks: <cite style="font-style:italic">Vom Mythos des Mann-Monats: Essays über Software-Engineering</cite>. mitp, Bonn 2003, ISBN 3-8266-1355-4.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Anti-Pattern&rft.au=Frederick+P.+Brooks&rft.btitle=Vom+Mythos+des+Mann-Monats%3A+Essays+%C3%BCber+Software-Engineering&rft.date=2003&rft.genre=book&rft.isbn=3826613554&rft.place=Bonn&rft.pub=mitp" style="display:none"> </span></li>

<li>William J. Brown et al.: <cite style="font-style:italic">Anti-patterns. Refactoring Software, Architecture and Projects in Crisis</cite>. John Wiley & Sons, New York 1998, ISBN 0-471-19713-0.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Anti-Pattern&rft.au=William+J.+Brown+et+al.&rft.btitle=Anti-patterns.+Refactoring+Software%2C+Architecture+and+Projects+in+Crisis&rft.date=1998&rft.genre=book&rft.isbn=0471197130&rft.place=New+York&rft.pub=John+Wiley+%26+Sons" style="display:none"> </span></li>

<li>Martin Fowler: <cite style="font-style:italic">Refactoring: Improving the Design of Existing Code</cite>. Addison-Wesley, Reading/Massachusetts 1999, ISBN 0-201-48567-2.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Anti-Pattern&rft.au=Martin+Fowler&rft.btitle=Refactoring%3A+Improving+the+Design+of+Existing+Code&rft.date=1999&rft.genre=book&rft.isbn=0201485672&rft.place=Reading%2FMassachusetts&rft.pub=Addison-Wesley" style="display:none"> </span></li>

<li>Joshua Kerievsky: <cite style="font-style:italic">Refactoring to Patterns</cite>. Addison-Wesley, Boston 2004, ISBN 0-321-21335-1.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Anti-Pattern&rft.au=Joshua+Kerievsky&rft.btitle=Refactoring+to+Patterns&rft.date=2004&rft.genre=book&rft.isbn=0321213351&rft.place=Boston&rft.pub=Addison-Wesley" style="display:none"> </span></li>

<li>Bruce A. Tate: <cite style="font-style:italic">Bitter Java</cite>. Manning, Greenwich/Connecticut 2002, ISBN 1-930110-43-X.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Anti-Pattern&rft.au=Bruce+A.+Tate&rft.btitle=Bitter+Java&rft.date=2002&rft.genre=book&rft.isbn=193011043X&rft.place=Greenwich%2FConnecticut&rft.pub=Manning" style="display:none"> </span></li>

<li>Bruce A. Tate et al.: <cite style="font-style:italic">Bitter EJB</cite>. Manning, Greenwich/Connecticut 2003, ISBN 1-930110-95-2.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Anti-Pattern&rft.au=Bruce+A.+Tate+et+al.&rft.btitle=Bitter+EJB&rft.date=2003&rft.genre=book&rft.isbn=1930110952&rft.place=Greenwich%2FConnecticut&rft.pub=Manning" style="display:none"> </span></li>

<li>Gerald M. Weinberg: <cite style="font-style:italic">Psychologie des Programmierers</cite>. mitp, Bonn 2004, ISBN 3-8266-1465-8.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Anti-Pattern&rft.au=Gerald+M.+Weinberg&rft.btitle=Psychologie+des+Programmierers&rft.date=2004&rft.genre=book&rft.isbn=3826614658&rft.place=Bonn&rft.pub=mitp" style="display:none"> </span></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="Syntaktischer_Zucker" title="Syntaktischer Zucker">Syntaktischer Zucker</a> und <a href="Syntaktisches_Salz" class="mw-redirect" title="Syntaktisches Salz">Syntaktisches Salz</a></li>

<li><a href="Technische_Schulden" title="Technische Schulden">Technische Schulden</a></li>

<li><a href="Gegenbeispiel" title="Gegenbeispiel">Gegenbeispiel</a> – bedeutungsähnliches Wort, auch in anderen Fachbereichen</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li><a rel="nofollow" class="external text" href="http://c2.com/cgi/wiki?AntiPattern">Anti-Pattern-Definition, Portland Pattern Repository</a> (englisch)</li>

<li><a rel="nofollow" class="external text" href="http://c2.com/cgi/wiki?AntiPatternsCatalog">Anti-Pattern-Katalog, Portland Pattern Repository</a> (englisch)</li>

/* start https://de.wikipedia.org/ */

.mw-parser-output .webarchiv-memento a{color:inherit}

/* end https://de.wikipedia.org/ */

</style><a rel="nofollow" class="external text" href="https://web.archive.org/web/20100204134231/http://www.mindview.net/WebLog/log-0056">Bruce Eckel: Programmer Experience Clumping und Faux System Architects (englisch)</a> (<span class="webarchiv-memento"><a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a></span> vom 4. Februar 2010 im <i><a href="Internet_Archive" title="Internet Archive">Internet Archive</a></i>)</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-BROOKS-1"><span class="mw-cite-backlink"><a href="#cite_ref-BROOKS_1-0">↑</a></span> <span class="reference-text">Frederick P. Brooks, Jr.: <i>The Mythical Man-Month</i>. Addison-Wesley, 1995 [1975].</span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><a href="#cite_ref-2">↑</a></span> <span class="reference-text">Guido Stepken: <a rel="nofollow" class="external text" href="https://web.archive.org/web/20150215041818/http://www.little-idiot.de/teambuilding/AntiPatternSoftwareentwicklung.pdf">Anti-Patterns in der Softwareentwicklung</a> (<span class="webarchiv-memento"><a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a></span> vom 15. Februar 2015 im <i><a href="Internet_Archive" title="Internet Archive">Internet Archive</a></i>; PDF; 308 kB) auf der Webseite little-idiot.de</span>

</li>

<li id="cite_note-integrationdatabase-3"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-integrationdatabase_3-0">a</a></sup> <sup><a href="#cite_ref-integrationdatabase_3-1">b</a></sup></span> <span class="reference-text">Michael T. Nygard: <cite class="lang" lang="en" dir="auto" style="font-style:italic">Release It! Design and Deploy Production-Ready Software</cite>. O’Reilly, 2007, ISBN 978-0-9787392-1-8, Dependencies between Systems: Databases (englisch, 326 S.).<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abookitem&rfr_id=info:sid/de.wikipedia.org:Anti-Pattern&rft.atitle=Dependencies+between+Systems%3A+Databases&rft.au=Michael+T.+Nygard&rft.btitle=Release+It%21+Design+and+Deploy+Production-Ready+Software&rft.date=2007&rft.genre=bookitem&rft.isbn=9780978739218&rft.pub=O%E2%80%99Reilly" style="display:none"> </span></span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><a href="#cite_ref-4">↑</a></span> <span class="reference-text"> A. W. Appel: <i>Modern Compiler Implementation in Java</i>. Cambridge University Press, 1998.</span>

</li>

<li id="cite_note-5"><span class="mw-cite-backlink"><a href="#cite_ref-5">↑</a></span> <span class="reference-text"><i>The Psychology of Science: a reconnaissance</i>; englisch; von <a href="Abraham_Maslow" title="Abraham Maslow">Abraham H. Maslow</a>, erstveröffentlicht 1966 (<i>First Edition, Januar 1966</i>), über den <i><a href="HarperCollins" title="HarperCollins">HarperCollins</a></i>-Verlag, ISBN 0-06-034145-9.</span>

</li>

<li id="cite_note-6"><span class="mw-cite-backlink"><a href="#cite_ref-6">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.oxfordreference.com/display/10.1093/oi/authority.20110803100218343"><i>mushroom management.</i></a> In: <i>Oford Reference.</i><span class="Abrufdatum"> Abgerufen am 30. November 2022</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AAnti-Pattern&rft.title=mushroom+management&rft.description=mushroom+management&rft.identifier=https%3A%2F%2Fwww.oxfordreference.com%2Fdisplay%2F10.1093%2Foi%2Fauthority.20110803100218343"> </span></span>

</li>

<li id="cite_note-7"><span class="mw-cite-backlink"><a href="#cite_ref-7">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="http://c2.com/cgi/wiki?YetAnotherMeetingWillSolveIt"><i>YetAnotherMeetingWillSolveIt.</i></a> In: <i>wiki.c2.com.</i> 17. April 2011,<span class="Abrufdatum"> abgerufen am 7. Januar 2018</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AAnti-Pattern&rft.title=YetAnotherMeetingWillSolveIt&rft.description=YetAnotherMeetingWillSolveIt&rft.identifier=http%3A%2F%2Fc2.com%2Fcgi%2Fwiki%3FYetAnotherMeetingWillSolveIt&rft.date=2011-04-17&rft.language=en"> </span></span>

</li>

<li id="cite_note-8"><span class="mw-cite-backlink"><a href="#cite_ref-8">↑</a></span> <span class="reference-text">Harold S. Geneen: <cite style="font-style:italic">The case for managing by the numbers</cite>. Hrsg.: Fortune. <span style="white-space:nowrap">Band<span style="display:inline-block;width:.2em"> </span>110</span>, <span style="white-space:nowrap">Nr.<span style="display:inline-block;width:.2em"> </span>7</span>, 1984, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>78–81</span>.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Anti-Pattern&rft.au=Harold+S.+Geneen&rft.btitle=The+case+for+managing+by+the+numbers&rft.date=1984&rft.genre=book&rft.issue=7&rft.pages=78-81&rft.volume=110" style="display:none"> </span></span>

</li>

<li id="cite_note-9"><span class="mw-cite-backlink"><a href="#cite_ref-9">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="http://blog.ninlabs.com/2013/01/programmer-interrupted/"><i>Programmer Interrupted.</i></a> Ninlabs Research, 19. Januar 2013,<span class="Abrufdatum"> abgerufen am 8. Februar 2013</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AAnti-Pattern&rft.title=Programmer+Interrupted&rft.description=Programmer+Interrupted&rft.identifier=http%3A%2F%2Fblog.ninlabs.com%2F2013%2F01%2Fprogrammer-interrupted%2F&rft.publisher=Ninlabs+Research&rft.date=2013-01-19"> </span></span>

</li>

<li id="cite_note-pi-strategie-10"><span class="mw-cite-backlink"><a href="#cite_ref-pi-strategie_10-0">↑</a></span> <span class="reference-text">Chris Parnin, Spencer Rugaber: <cite style="font-style:italic">Resumption strategies for interrupted programming tasks</cite>. In: <cite style="font-style:italic">17th International Conference on Program Comprehension</cite>. IEEE, 2009, <a href="Digital_Object_Identifier" title="Digital Object Identifier">doi</a>:<span class="uri-handle" style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://doi.org/10.1109/ICPC.2009.5090030">10.1109/ICPC.2009.5090030</a></span> (<a rel="nofollow" class="external text" href="https://web.archive.org/web/20181021065934/https://www.cc.gatech.edu/reverse/repository/resumptionstrategies.pdf">cc.gatech.edu</a> (<span class="webarchiv-memento"><a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a></span> vom 21. Oktober 2018 im <i><a href="Internet_Archive" title="Internet Archive">Internet Archive</a></i>) [PDF; <span style="white-space:nowrap">266<span style="display:inline-block;width:.2em"> </span>kB</span>]).<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Anti-Pattern&rft.atitle=Resumption+strategies+for+interrupted+programming+tasks&rft.au=Chris+Parnin%2C+Spencer+Rugaber&rft.btitle=17th+International+Conference+on+Program+Comprehension&rft.date=2009&rft.doi=10.1109%2FICPC.2009.5090030&rft.genre=book&rft.pub=IEEE" style="display:none"> </span></span>

</li>

<li id="cite_note-11"><span class="mw-cite-backlink"><a href="#cite_ref-11">↑</a></span> <span class="reference-text"><span class="cite">Shamsi T. Iqbal, Xianjun Sam Zheng, Brian P. Bailey: <a rel="nofollow" class="external text" href="https://dl.acm.org/doi/10.1145/985921.986094"><i>Task-evoked pupillary response to mental workload in human-computer interaction.</i></a> 2004,<span class="Abrufdatum"> abgerufen am 8. Februar 2013</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AAnti-Pattern&rft.title=Task-evoked+pupillary+response+to+mental+workload+in+human-computer+interaction&rft.description=Task-evoked+pupillary+response+to+mental+workload+in+human-computer+interaction&rft.identifier=https%3A%2F%2Fdl.acm.org%2Fdoi%2F10.1145%2F985921.986094&rft.creator=Shamsi+T.+Iqbal%2C+Xianjun+Sam+Zheng%2C+Brian+P.+Bailey&rft.date=2004&rft.language=en"> </span></span>

</li>

<li id="cite_note-12"><span class="mw-cite-backlink"><a href="#cite_ref-12">↑</a></span> <span class="reference-text"><span class="cite">James Fogarty, Andrew J. Ko, Htet Htet Aung, Elspeth Golden, Karen P. Tang, Scott E. Hudson: <a rel="nofollow" class="external text" href="https://dl.acm.org/doi/10.1145/1054972.1055018"><i>Examining task engagement in sensor-based statistical models of human interruptibility.</i></a> 2005,<span class="Abrufdatum"> abgerufen am 8. Februar 2013</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AAnti-Pattern&rft.title=Examining+task+engagement+in+sensor-based+statistical+models+of+human+interruptibility&rft.description=Examining+task+engagement+in+sensor-based+statistical+models+of+human+interruptibility&rft.identifier=https%3A%2F%2Fdl.acm.org%2Fdoi%2F10.1145%2F1054972.1055018&rft.creator=James+Fogarty%2C+Andrew+J.+Ko%2C+Htet+Htet+Aung%2C+Elspeth+Golden%2C+Karen+P.+Tang%2C+Scott+E.+Hudson&rft.date=2005"> </span></span>

</li>

<li id="cite_note-13"><span class="mw-cite-backlink"><a href="#cite_ref-13">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="http://www.hadermann.be/blog/46/the-hidden-cost-of-interrupting-knowledge-workers/"><i>The hidden cost of interrupting knowledge workers.</i></a> 5. Oktober 2009,<span class="Abrufdatum"> abgerufen am 8. Februar 2013</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AAnti-Pattern&rft.title=The+hidden+cost+of+interrupting+knowledge+workers&rft.description=The+hidden+cost+of+interrupting+knowledge+workers&rft.identifier=http%3A%2F%2Fwww.hadermann.be%2Fblog%2F46%2Fthe-hidden-cost-of-interrupting-knowledge-workers%2F&rft.date=2009-10-05"> </span></span>

</li>

</ol></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-08-04" href="https://de.wikipedia.org/wiki/?title=Anti-Pattern&oldid=258590047">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>